The Metro Ethernet Forum specifies the services provided by the Metro Ethernet Network (MEN), the interfaces to the MEN, and the attributes that characterize the services and interfaces.
FIG. 1 is a simplified block diagram of a MEN 11 illustrating a plurality of User Network Interfaces A-C (UNIs) 12a-12c between the MEN and Customer Equipments (CEs) 13a-13c. If the MEN is implemented with 802.1 technology, the MEN is equivalent to a Provider Bridged Network (802.1ad). As shown in FIG. 1, each UNI is a demarcation between the MEN and a CE. The frame format at the UNI is an untagged or C-tagged Ethernet frame. UNIs provide a Port-based and C-tagged service interface. An Ethernet Virtual Connection (EVC) is an association of UNIs such that any ingress customer frame mapped to an EVC at a UNI may be delivered to any or all other UNIs that have mappings to the same EVC. FIG. 1 illustrates two EVCs. EVC-1 associates UNI A and UNI B, and EVC-2 associates UNI A, UNI B, and UNI C. For a Provider Bridged Network, the EVC is a service instance implemented by a Service Virtual Local Area Network (S-VLAN) and identified by an S-VLAN Identifier (S-VID).
FIG. 2 is a simplified block diagram of two Operator MENs 21 and 22 connected by an External Network Network Interface (E-NNI) 23. In the MEF model, there is a Service Provider responsible for the end-to-end service offered to a customer. The Service Provider may contract with one or more Operators, each responsible for a MEN, to realize the service. The Service Provider may (or may not) be one of the Operators. The E-NNI is a reference point representing the boundary between two Operator MENs that are operated as separate administrative domains.
The physical medium at the E-NNI 23 is a full-duplex 802.3 LAN. The frame format at the E-NNI is an S-tagged 802.3 frame. The S-VID is a service identifier that enables the operator on either side of the E-NNI to map frames to the appropriate Operator Virtual Connection (OVC) End Point.
An EVC 24 is an end-to-end (UNI-to-UNI) service instance. An OVC is a local (to one Operator MEN) service instance. FIG. 2 illustrates a first OVC 25 for MEN 21 and a second OVC 26 for MEN 22. In many cases there is a one-to-one relationship within a given Operator MEN between an OVC and an EVC; however this is not true in all cases. The arrows at the bottom of FIG. 2 provide a simple example to illustrate the OVCs 25 and 26 and the EVC 24.
FIG. 3 is a simplified block diagram of two Operator MENs 31 and 32 in which a service provider provides a multipoint EVC to a customer. The MENs are connected by E-NNI 33. Under certain circumstances, a service provider may not want to disclose or delegate to other operators any details of the service being provided to the customer. The service provider may provide multipoint service to customers but only purchase point-to-point OVCs from another operator's MEN. In the example shown in FIG. 3, Service Provider A provides a multipoint EVC to a customer with sites UNI A 34a, UNI B 34b, UNI E 34e, and UNI D 34d. Service Provider A also owns MEN A 31 (i.e., Service Provider A is also MEN A's Operator). To keep the customer information secret and reduce the operation cost. Service Provider A only buys two point-to-point OVCs from the Operator of MEN B 32.
A problem arises when a frame is sent from UNI E 34e with the destination of UNI D 34d. Because Service Provider A only uses two point-to-point OVCs from MEN B 32, this frame needs to be received by MEN A 31 at a port of the E-NNI 33 and be transmitted on the same physical port to UNI D 34d with a different S-VID. This process is referred to as “hairpin switching” and is not supported by current Provider Edge Bridges.
FIG. 4 is a simplified block diagram of two Operator MENs 41 and 42 in which a service provider provides services to a customer located in another operators MEN in a process similar to the “hairpin switching” of FIG. 3. The MENs are connected by E-NNI 43. Service Provider A provides two (or more) EVCs to UNI D 44d, which is located in MEN B. Service Provider A owns MEN A but not MEN B. The straightforward solution shown in FIG. 4 is for Service Provider A to obtain an OVC per EVC from Operator B and have Operator B perform the service multiplexing functionality.
However, Service Providers may not like this solution for several reasons. First, it requires Service Provider A to buy multiple OVCs from Operator B and disclose the details of its customer information. Second, Service Provider A must coordinate with Operator B whenever there is a change of services such as the number of EVCs provided to UNI D.
FIG. 5 is a simplified block diagram of two Operator MENs 51 and 52 in which a Virtual UNI (VUNI) 53 on the MEN A side of the E-NNI 54 performs service multiplexing and other UNI functions. If the MEN uses 802.1 technology, implementing the VUNI at the E-NNI requires a de-multiplexing function to first de-multiplex frames received at the E-NNI based on the S-VID, and then perform the normal Provider Edge Bridge function of mapping frames to EVCs based on the Customer VLAN Identifier (C-VID). The VUNI is not supported by current Provider Edge Bridges.
FIG. 6 is a simplified block diagram of an existing Provider Edge Bridge Model 61. In 802.1ad (Provider Bridging), a new Service VLAN tag is defined for use in provider networks. So the bridges at the edge of a Provider Bridged Network need to operate on both Customer VLAN (C-VLAN) tags and Service VLAN (S-VLAN) tags. A Provider Edge Bridge contains at least one C-VLAN component 62 (one per customer) with an internal connection per service instance to an S-VLAN component 63. The C-VLAN component includes a Customer Edge Port (CEP) 64 that is connected to customer-owned equipment and receives and transmits frames for a single customer. The C-VLAN component also includes at least one Provider Edge Port (PEP) 65 that connects to a Customer Network Port (CNP) 66 on the S-VLAN component and receives and transmits frames for a single customer. The S-VLAN component includes at least one CNP that receives and transmits frames for a single customer. The S-VLAN component also includes a Provider Network Port (PNP) 67 that can transmit and receive frames for multiple customers.
FIG. 7 is a simplified block diagram of a Provider Edge Bridge Model 71 proposed in IEEE 802.1Qbc/D0.0 to address the “Hairpin Switching” and “VUNI” problems in Provider Bridged Networks. Multiple remote customer service interfaces can be provided over a LAN interconnecting two Provider Bridged Networks through the use of an S-VLAN mapping component 72 as shown in FIG. 7.
The model specifies that the S-VLAN mapping component 72 relays frames between a common port (e.g., PNP in the S-VLAN mapping component 72) and a set of (internal) LANs 73, where each internal LAN provides a remote customer service interface 74 associated with a single service VID. The S-VLAN mapping component 72 is a limited function S-VLAN component that relays frames between one S-VLAN-tagged external LAN and the set of internal LANs each of which provides a single service interface. Frames belonging to a Remote Customer Service Interface (R-CSI) are identified by a unique service VID and are mapped to and from a distinct internal LAN.
An R-CSI may connect to a C-VLAN component 75 to provide a C-tagged service interface (i.e., to provide VUNI) or may be directly connected to the Provider Bridge's S-VLAN component 76 to provide a Port-based interface (i.e., to provide Hairpin Switching). One internal LAN 77 may provide an S-tagged service interface between the PBNs, and multiple service VIDs may be mapped to this interface. It is connected directly to the Provider Bridge's S-VLAN component 76 and provides an S-tagged service interface.
The problem with the existing remote customer service interface (R-CSI) solution is that it requires the new S-VLAN Mapping component 72. This requires additional new hardware to support the new functionalities and the standardized C-VLAN component 62 and S-VLAN component 63 cannot be reused. Thus, the solution is expensive and undesirable.